Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/ospf/ospf-minutes-91nov.txt

Text File | 1993-02-17 | 12KB | 289 lines

CURRENT_MEETING_REPORT_


Reported by John Moy/Proteon

Minutes of the Open Shortest Path First IGP Working Group (OSPF)

The OSPF Working Group met Tuesday November 19, 1991 at the Santa Fe
IETF. The Minutes of the Working Group meeting follow.  In addition, at
this IETF work was performed (and decisions were made) in other working
groups affecting OSPF. This related work is summarized below in the
liaison section.



  1. Liason With Other Working Groups


       o In the Open IESG meeting, it was announced that the IAB had
         approved the OSPF Applicability Statement, which recommends the
         use of OSPF as the Common IGP. It is expected that the
         Applicability statement will be published as an RFC.

       o The wording of the router requirements document now reads:  if
         a router implements dynamic routing, it must implement OSPF (as
         an aside, it also must implement RIP). Router requirements has
         also made TOS in OSPF optional (this was part of a more general
         discussion of whether further subsets of OSPF are possible
         and/or useful, which was continued at the OSPF Working Group
         meeting; see Section 2.5 below).  The router requirements
         Working Group has also asked that the behavior of OSPF in the
         face of database overflows be written down.  Finally, an IP
         Forwarding Table MIB has been defined allowing network
         management stations to dump equal-cost routes, and routes that
         depend on TOS (both of which are possible with OSPF).

       o The BGP Working Group has been working on a document specifying
         the interaction between BGP and OSPF. A first draft of this
         document, written by Kannan Varadhan of OARNet, had been
         published as an Internet Draft before the Santa Fe IETF. At the
         IETF the sections describing route exchange, the setting of BGP
         IDs and OSPF Router IDs, and the setting of the BGP NEXT_HOP
         attribute and the OSPF forwarding address were pretty much
         agreed upon.  The setting of the tag field in type 5 AS
         external LSAs was more controversial, and several different
         proposals were floated.  An updated Internet Draft should
         appear shortly.


  2. Working Group Minutes

     The following items were discussed in the Working Group session.
     All items on the Agenda were covered, except for a planned

                                   1





discussion of OSPF's non-broadcast network support (which is a hot
topic currently because of all the activity in the IPLPDN group).

(a) A Problematic Virtual Link Configuration

    A handout was provided describing a configuration of virtual
    links that was found to create routing loops.  This
    configuration was discovered during the last round of OSPF
    testing, immediately prior to Interop '91.  Basically, the
    problem arises because, in a virtual link's transit area, the
    area border routers may have a different view of routing than
    the area's internal routers.  The current OSPF specification
    tries to deal with this by have the endpoints of a virtual link
    run an extra computation:  the ``resolution of virtual next
    hops'' described in Section 13.3 of the spec.
    However, this is not enough to avoid loops in all
    configurations, as the handout showed.  The handout also
    presented a fix to the spec, whereby any router bordering
    transit areas would a) keep track of all transit areas that are
    traversed on route to any particular destination and b) for
    such a destination, run the ``resolution of virtual next hops''
    using summary links belonging to each of the traversed areas.

    It was generally felt that the handout's fix was too
    complicated.  An alternative fix, involving less bookkeeping
    while potentially running the ``resolution of virtual next
    hops'' process on more destinations, was proposed.  This
    simpler fix is being investigated.

    The handout, augmented with a discussion of the simpler fix,
    will be published as an Internet Draft.  Eventually, a new (but
    backward-compatible) version of the OSPF specification will
    have to be published.  Besides having a fix for the virtual
    link problem, it was proposed to at that time add the
    following:  a) make the origination of summary-LSAs into stub
    areas optional and b) Add text describing how to avoid
    originating summary-LSAs into an area when you know that they
    will never be used (i.e., when the first hop for the
    destination belongs to the area itself; this is sort of
    equivalent to split horizon in a Bellman-Ford algorithm).

(b) Proposed Changes to the OSPF MIB

    The following changes to the OSPF MIB were proposed.  It is the
    intent that all these changes be backward-compatible with the
    present MIB:

     o Change the range of the ospfIfRtrDeadInterval,
       ospfIfPollInterval and ospfVirtIfRtrDeadInterval variables
       from 0-0xffffffff to 0-0x7fffffff.  This is being done to
       make life easier for MIB compilers, realizing that it

                              2





       doesn't really make any sense to set the variables higher
       than 0x7fffffff anyway.

     o Remove the TOSType definition from the OSPF MIB, and instead
       refer to a TOS definition in the new IP Forwarding Table
       MIB.

     o Add a separate table for type 5 AS externals, removing them
       from the current ospfLsdbTable.  At the moment it is not
       clear just where in the ospfLsdbTable the type 5 AS
       externals should go.

     o Add type 6 (group-membership-LSAs) and type 7 (the new NSSA
       externals) LS types to the ospfLsdbTable.  This will allow
       us to monitor the OSPF extensions (somewhat) from the base
       OSPF MIB.

     o Add a boolean to the Area Table allowing you to turn on or
       off the origination of summary-LSAs into stub areas.

     o Somehow figure out how to represent OSPF type 1 and type 2
       metrics, and also the four level OSPF routing hierarchy
       (intra-area, inter-area, type 1 external and type 2
       external) in the new IP Forwarding Table MIB. This may be
       done entirely with comments.

    There was an additional proposal on the table to clean
    up/rationalize the ascii names of some of the OSPF MIB
    variables.  It was decided to ask the Network Management
    Directorate whether this would be too large a change to make at
    this time.

(c) The OSPF Trap MIB

    Rob Coltun reported on the state of the OSPF Trap MIB. There
    are currently twelve traps:  Interface state change (regular
    and virtual), Neighbor state change (regular and virtual),
    Configuration error (over real and virtual links), Receive bad
    packet (over regular and virtual links), Packet retransmission
    (over regular and virtual links), Originate LSA and MaxAge LSA.
    Each trap can be enabled and disabled separately.  Trap
    origination is rate-limited, and traps are inhibited for the
    first 2*DeadInterval seconds after a router comes up.

    It was decided to add two more traps.  The first indicates that
    the link state database has overflowed.  The second indicates
    that the link state database is close to overflowing, because
    available resources having dropped below some configurable
    threshold (units of the threshold being number of LSAs).

    After making these additions, the document will be published as
    an Internet Draft.

                              3





(d) Current Proposal for OSPF NSSA Areas

    Rob Coltun presented the current proposal for OSPF NSSA areas.
    His viewgraphs will appear in the IETF proceedings.  A brief
    summary of his presentation follows:
     o An NSSA area (Not so stubby area) is a new kind of area
       which does not process type 5 external LSAs (reducing memory
       resource requirements) but which can originate external
       routing information and pass it on to the rest of the OSPF
       system.  For example, an NSSA area can be used where you
       wanted to use an OSPF stub area, but couldn't because
       hanging hanging off of the area was a RIP cloud.

     o External routes are originated into an NSSA area via a new
       link state advertisement:  type 7 LSAs.  The format of type
       7 LSAs are identical to type 5 LSAs.  However, type 7s are
       specific to a single NSSA area only.  There will be a
       propagate bit in the type 7 LSA's Options field which
       indicates whether the type 7 LSA should be translated into a
       type 5 LSA at the NSSA border.  Those type 7 LSAs which are
       to be translated MUST specify a forwarding address (this
       makes translation into type 5 LSAs simple, and also enables
       a simple already specified tie-breaking mechanism ensuring
       that only one border router does the translation).

     o Area border routers attached to NSSAs originate a type 7 LSA
       specifying the default route (with the propagate bit off)
       into the NSSA. This compensates for the fact that type 5
       LSAs are not flooded into NSSAs.  Also, to maintain the OSPF
       routing hierarchy area border routers attached to NSSAs must
       summarize the internal (intra-area and inter-area) OSPF
       routes into the NSSA (for OSPF stub areas this summarization
       is optional).

    Several other possible NSSA features were discussed, namely:
    a) allowing type 7 information to be collapsed (instead of
    directly translated) at NSSA boundaries and b) allowing
    selective reverse translation at NSSA boundaries (i.e., type 5
    LSAs into type 7 LSAs for propagation into the NSSA). It was
    decided to leave both features outside the scope of the NSSA
    option.

(e) Defining a Minimal Subset of OSPF

    We spent some time discussing whether it was useful to subset
    OSPF beyond simply making TOS optional.  It was generally
    agreed that this would probably not be a commercially viable
    product, since the router would be limited to only certain
    places in the topology.  However, it did appear that it might
    be viable for those products that naturally reside at the edge
    of the IP routing domain, for example, the Shiva FastPath box.


                              4





  3. Action Items


       o Revise the OSPF specification with a fix for the virtual link
         problem [John Moy]

       o Revise the OSPF MIB [Fred Baker]

       o Publish the OSPF Trap MIB as an Internet Draft [Rob Coltun]

       o Document the NSSA option and publish as an Internet Draft [Rob
         Coltun and Vince Fuller]

       o Outline the possibilities for a minimal OSPF implementation
         [John Moy with help from Shiva and Cayman Systems].

       o Document the OSPF response to database overflow [John Moy]



Attendees

Steve Alexander          [e-mail]
Fred Baker               [e-mail]
James Barnes             [e-mail]
James Beers              [e-mail]
David Bolen              [e-mail]
Gregory Bruell           [e-mail]
Dean Cheng               [e-mail]
Kenneth Crepea           [e-mail]
John Damiano
Kurt Dobbins             [e-mail]
Christine Hemrick        [e-mail]
Ronald Jacoby            [e-mail]
April Merrill            [e-mail]
Dean Morris              [e-mail]
John Moy                 [e-mail]
Thomas Pusateri          [e-mail]
Manoel Rodrigues         [e-mail]
Sharad Sanghi            [e-mail]
Stephen Shew             [e-mail]
Richard Smith            [e-mail]
Frank Solensky           [e-mail]
Ravi Srinivasan          [e-mail]
Yuan Wang                natadm![e-mail]
Scott Wasson             [e-mail]
Osmund de Souza          [e-mail]



                                   5